DEMoS Manifesto

This is a manifesto for DEMoS, which is a Distributed Embedded Modular System, but also a manifesto addressing the need for more inter-/cross-disciplinary mastery of working knowledge related to installing this class of systems in the real world. There is somehow room for yet another class of systems complementary to existing embedded systems complementing distributed operating systems which takes on an interdisciplinary cyber-physical-materiality approach, a dedicated holistic perspective that recognizes the true value of interdisciplinary mastery vs. the implicit and overlooked expense of narrow intra-disciplinary focus dominating much of systems development (e.g. EE, CE, CS, SE, and IS). Interdisciplinary mastery yields its accumulated value across the development, deployment, use, re-use, and decommission phases for this class of systems: DEMoS is a system architected to be locally distributed, embedded, and modular as outlined herein and with the additional goals of human interdisciplinary mastery in this context: A potential set of goals for developing and applying DEMoS can be found in UN Resolution 70/1. In DEMoS [6] (demos also means ’common people’ ), the host SW tooling is mainly limited to multi-paradigm languages with open source implementations, e.g. the succinct F# (in close competition with say C#, but also other languages). For low-level HW description/verification, the Verilog HDL family is (with no serious competition) chosen: System Verilog emerging as the likely specific candidate. It is considered if transpiling (a sync./async. variant) of F# to (System) Verilog is worth-while endeavor in one form or the other. On the embedded side, it would seem that any language with compiler support for the implemented instruction set is possible. However, multiple source language support (even from within the native .NET family) is most likely not practical on the target side (polyglot programming is harder in the embedded space!). In this case, F# [8] seems to offer a realistic compromise between the different programming paradigms (supporting both functional and/or OO programming. For PCB support of being distributed and modular, a system based on high-density interconnects is considered. Interconnects are currently thought to be based on Z-Ray® 1.0 mm micro arrays, and I call it ZMOD. Considering also soldering, it, ZMOD, would make a kind of two-sided PCB available, while only demanding single sided SMD processes; not an irrelevant consideration from a 1 ar X iv :1 61 2. 04 19 1v 1 [ cs .O H ] 1 1 D ec 2 01 6 maker perspective [1]. IO and some aspects of system control is thought to include use of PC/mobile phone audio ports with supporting target circuitry. For example, it opens up for programs or apps that support the the developer in some situations and the users in other scenarios. Just consider trouble-shooting complete (perhaps even remote) systems like drones, autonomous cars, robots, vessels or smaller power plant set-ups. Furthermore, is it considered what USB/JTAG solution to use. FTDI offers non-programmable and programmable USB solutions. Programmable USB solutions (e.g. VNC2) offer one way to deal with some IO mess (like audIO/UART/SPI/modems/WiFi/WiFi beacon-based protocols/BT/NFC/JTAG etc.), but with the annoyance of another SDK to learn. For low-speed/high-speed, small/wide, and wired/wireless interconnects to other cores, systems, transceivers, etc., a language independent specification is considered to be useful. For instance, to define mods based on the Z-Ray® micro arrays, XML or JSON-LD seem good formats for this task. Another interconnect type that might prove useful is the wellknown ethernet cable, as it is easy to cut into any desired length and connect to other ”distant” (centimeters to meters away) DEMoS systems. Within one DEMoS system, a specialized processor, targeting the CIL instructions, called CILOP, is situated between DEMoS and the physical cores. One CILOP is similar to one Java Optimized Processor [7]. The (physical) cores, currently referred to as Thunder-cores (TCORE), are sought to have a non-rigid relationship to the operating system modules thus achieving distribution primarily within the embedded context. One DEMoS could encompass many CILOPS, and those CILOPs could be run over multiple TCOREs, and those TCOREs could be spread across multiple FPGAs. It should be noted that a future, but both difficult and expensive, yet very interesting, option would be to ”harden” the CILOP using services such as ”The MOSIS Service”. Coming back to the context, and thus the meaning of being distributed, is different for embedded systems than for general distributed (operating) systems [3]. Distributed execution i.e. as in one robot demands extreme care and understanding of the development environments/tools/processes as it is not trivial to develop multiple systems (with separate debug cables etc.) as one conceptional DEMoS. A basic un-distributed canonical implementation could consist of just one DEMoS running in one Thunder-core. Thunder-cores must support efficient average execution as well as real time applications. Needed ML/AI precision should be addressed by sensible FPU [2] support carefully balancing both FPGA cost and library implementation. Thunder-cores execute on an ISA currently aligned to ECMA-335, Partition III, because it is important to retain a close link to the fundamental binary execution units (.DLL and .exe). Flexible hardware is chosen in the form of affordable FPGAs/CPLDs, which allows more room for form to follow function, and function to follow form, in a wide spectrum of imaginable use cases with the developer possibly taking on an additional action research role. To support and exploit the marvelous FPGAs, specialized hardware is considered, such as optimized memory modules for garbage collection, stack fill/spill, context switching, process/app/OS migration, virtualization, and (large) (shared) caches; the latter most likely an important component to achieve meaningful distribution of data and computation. Considering the